Files that changed from the base of the PR and between 0c663b7 and 569abfd.

• orderbook/usecase/export_test.go is excluded by !**/*_test.go
• orderbook/usecase/orderbook_usecase_test.go is excluded by !**/*_test.go
• passthrough/delivery/http/passthrough_handler_test.go is excluded by !**/*_test.go

• app/sidecar_query_server.go (1 hunks)
• delivery/http/event.go (1 hunks)
• domain/mocks/orderbook_usecase_mock.go (2 hunks)
• domain/mvc/orderbook.go (1 hunks)
• domain/orderbook/order.go (1 hunks)
• orderbook/usecase/orderbook_usecase.go (1 hunks)
• passthrough/delivery/http/passthrough_handler.go (3 hunks)

domain/mvc/orderbook.go (1)

20-21: Add tests for the new GetActiveOrdersStream method

To address the comment about test coverage and meet the goal of 50% coverage, it's important to add tests for this new method. Testing asynchronous methods that return channels can be challenging, but it's crucial for ensuring the reliability of the SSE implementation.

Consider adding the following tests:

1. Test that the method returns a channel.
2. Test that the channel receives the expected ActiveOrder objects.
3. Test the behavior when the context is canceled.
4. Test with various input addresses, including edge cases.

Here's a shell script to check for existing tests related to this method:

If these tests don't exist, please add them to ensure proper coverage of the new functionality.

domain/mocks/orderbook_usecase_mock.go (1)

18-18: LGTM: New field for mocking GetActiveOrdersStream

The addition of GetActiveOrdersStreamFunc is consistent with the existing mock structure and allows for flexible mocking of the new GetActiveOrdersStream method.

domain/orderbook/order.go (1)

97-101: Verify the relationship between ActiveOrder and SSE implementation

The new ActiveOrder type seems to be related to the Server-Sent Events (SSE) implementation mentioned in the PR objectives. To ensure proper implementation:

1. Confirm that this type is indeed used for SSE responses in the Active Orders Query endpoint.
2. Verify if the IsBestEffort field is related to the real-time nature of SSE updates.
3. Ensure that the Error field is properly utilized to communicate issues during the SSE stream.

It would be helpful to see the code that uses this ActiveOrder type in the context of the SSE implementation to fully understand its role and ensure it meets the PR objectives.

To help verify the usage of ActiveOrder in the SSE implementation, you can run the following script:

This script will help identify where and how the ActiveOrder type is being used, particularly in relation to the SSE implementation.

app/sidecar_query_server.go (2)

206-206: Consider adding tests for the new SSE functionality

While this change is minimal, it's part of implementing Server-Sent Events (SSE) for the Active Orders Query endpoint. To address the concern raised in the PR comments about test coverage:

1. Consider adding unit tests for the NewPassthroughHandler function to ensure it correctly handles the new logger parameter.
2. Implement integration tests that verify the SSE functionality of the Active Orders Query endpoint, including both SSE and non-SSE scenarios.

These additions would help achieve the suggested 50% coverage threshold and ensure the reliability of the new feature.

To check the current test coverage for the passthrough package, run the following command:

#!/bin/bash
# Description: Check test coverage for the passthrough package

go test -coverprofile=coverage.out ./passthrough/...
go tool cover -func=coverage.out

This will help identify areas where additional test coverage might be needed.

---

206-206: LGTM! Consider verifying the NewPassthroughHandler implementation.

The addition of the logger parameter to the NewPassthroughHandler function call is a good improvement for observability. This change aligns well with the implementation of Server-Sent Events (SSE) for the Active Orders Query endpoint, as mentioned in the PR objectives.

To ensure the logger is properly utilized, please run the following script to check the NewPassthroughHandler function implementation:

This will help confirm that the logger parameter is being used effectively in the NewPassthroughHandler function.

Verification successful

---

Verification Successful: Logger Usage Confirmed

The logger parameter added to the NewPassthroughHandler function is properly utilized within the handler's methods for error logging. This enhancement improves observability and aligns with the implementation of Server-Sent Events (SSE) for the Active Orders Query endpoint.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the NewPassthroughHandler function is using the logger parameter

# Search for the NewPassthroughHandler function definition and its usage of the logger
rg --type go -A 10 'func NewPassthroughHandler.*logger' passthrough/delivery/http/

Length of output: 1451

---

Script:

#!/bin/bash
# Description: Verify that the logger is being used within the handler's methods

# Search for usages of the logger within passthrough_handler.go
rg 'handler\.Logger\.' passthrough/delivery/http/passthrough_handler.go

Length of output: 73

---

Script:

#!/bin/bash
# Description: Verify all usages of the logger within passthrough_handler.go

# Search for any usages of Logger within passthrough_handler.go
rg 'Logger\.' passthrough/delivery/http/passthrough_handler.go

Length of output: 209

delivery/http/event.go (1)

95-95: Verify that w.Flush() is supported by echo.Response

Ensure that the Flush() method is available and properly supported by the echo.Response object to prevent potential runtime errors.

Run the following script to confirm that echo.Response supports Flush():

passthrough/delivery/http/passthrough_handler.go (1)

42-42: Remove redundant route registration for '/active-orders'

At line 42, the route /active-orders is registered twice. The first registration with handler.GetActiveOrders is immediately overridden by the second registration starting at line 43. Registering the same route twice can lead to unexpected behavior, as the first registration will be ignored.

Apply this diff to remove the redundant route registration:

-	e.GET(formatPassthroughResource("/active-orders"), handler.GetActiveOrders)

Likely invalid or redundant comment.

orderbook/usecase/orderbook_usecase.go (1)

140-148: Reminder: Move constants to the top of the file

As previously mentioned, please move the constants fetchActiveOrdersDuration and getActiveOrdersStreamChanLen to the top of the file for consistency with other constant declarations.

Files that changed from the base of the PR and between 569abfd and cc3d892.

• orderbook/usecase/export_test.go is excluded by !**/*_test.go
• orderbook/usecase/orderbook_usecase_test.go is excluded by !**/*_test.go
• passthrough/delivery/http/passthrough_handler_test.go is excluded by !**/*_test.go

• app/sidecar_query_server.go (1 hunks)
• delivery/http/event.go (1 hunks)
• domain/mocks/orderbook_usecase_mock.go (2 hunks)
• domain/mvc/orderbook.go (1 hunks)
• domain/orderbook/order.go (2 hunks)
• orderbook/usecase/orderbook_usecase.go (2 hunks)
• passthrough/delivery/http/passthrough_handler.go (4 hunks)

• app/sidecar_query_server.go
• delivery/http/event.go
• domain/mocks/orderbook_usecase_mock.go
• domain/mvc/orderbook.go
• domain/orderbook/order.go

passthrough/delivery/http/passthrough_handler.go (6)

10-10: LGTM: New imports for logging.

The addition of the log and zap packages is appropriate for implementing logging functionality. Using zap is a good choice as it's a high-performance, structured logging library.

Also applies to: 16-16

---

23-23: LGTM: Logger field added to PassthroughHandler struct.

The addition of the Logger field to the PassthroughHandler struct is a good practice. It allows for dependency injection of the logger, enhancing flexibility and testability of the code.

---

33-33: LGTM: NewPassthroughHandler updated to include logger.

The NewPassthroughHandler function has been correctly updated to accept a logger parameter and assign it to the PassthroughHandler struct. This change is consistent with the addition of the Logger field and follows good dependency injection practices.

Also applies to: 37-37

---

42-47: LGTM: Routing updated to support SSE.

The routing logic has been updated to support Server-Sent Events (SSE) for the /active-orders endpoint. The implementation checks for the sse query parameter and routes to the appropriate handler. This approach maintains backward compatibility while adding the new SSE functionality, which is a good practice.

---

75-89: LGTM: New helper function for request parsing and validation.

The parseAndValidateGetActiveOrdersRequest helper function is a good addition. It encapsulates the request unmarshalling and validation logic, promoting code reuse and maintainability. This follows the DRY principle and improves the overall structure of the code.

---

167-168: LGTM: GetActiveOrders updated to use new helper function.

The GetActiveOrders method has been updated to use the new parseAndValidateGetActiveOrdersRequest helper function. This change improves code consistency and reduces duplication, aligning with the DRY principle.

orderbook/usecase/orderbook_usecase.go (4)

140-148: LGTM! Constants are well-defined and explained.

The addition of fetchActiveOrdersDuration and getActiveOrdersStreamChanLen with their explanatory comments addresses the previous review comment about explaining how these numbers were selected. The values seem reasonable for their intended purposes.

---

150-209: LGTM! SSE implementation looks good.

The GetActiveOrdersStream method successfully implements server-sent events for active orders, aligning with the PR objectives. The use of a buffered channel and a ticker for periodic fetching are appropriate approaches.

---

Line range hint 218-247: LGTM! Improvements to GetActiveOrders method.

The modifications to the GetActiveOrders method align well with the new OrderbookResult type. The changes provide more structured information and improve error handling and logging while maintaining the existing functionality.

---

Line range hint 1-577: Overall, the changes look good with room for improvement.

The implementation of Server-Sent Events (SSE) for the Active Orders Query endpoint is well done and aligns with the PR objectives. The code is generally well-structured and maintains existing functionality while adding new features.

Regarding the question about test coverage:

To address p0mvn's question about test coverage, let's check the current test coverage for this file:

This will help determine if additional tests are needed to meet the 50% coverage threshold. Based on the results, we can decide if more tests should be added, particularly for the new GetActiveOrdersStream method.

Files that changed from the base of the PR and between cc3d892 and 81d5aa6.

• delivery/http/http.go (2 hunks)
• delivery/http/trace.go (1 hunks)
• passthrough/delivery/http/passthrough_handler.go (4 hunks)
• validator/validator.go (1 hunks)

• passthrough/delivery/http/passthrough_handler.go

validator/validator.go (2)

1-11: Address PR objectives and test coverage

While this validator package provides a useful abstraction for validation, it doesn't directly address the PR's main objective of implementing Server-Sent Events (SSE) for the Active Orders Query endpoint. Could you clarify how this package fits into the larger implementation?

Additionally, as mentioned in the PR comments, there's a goal to achieve 50% test coverage. Consider adding unit tests for this package to contribute to that goal. Here's a simple example of what those tests might look like:

package validator

import (
	"errors"
	"testing"
)

type testValidator struct {
	shouldPass bool
}

func (tv testValidator) Validate() error {
	if tv.shouldPass {
		return nil
	}
	return errors.New("validation failed")
}

func TestValidate(t *testing.T) {
	tests := []struct {
		name    string
		v       Validator
		wantErr bool
	}{
		{"passing validation", testValidator{true}, false},
		{"failing validation", testValidator{false}, true},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			if err := Validate(tt.v); (err != nil) != tt.wantErr {
				t.Errorf("Validate() error = %v, wantErr %v", err, tt.wantErr)
			}
		})
	}
}

To check the current test coverage for this package:

#!/bin/bash
# Description: Check test coverage for the validator package

# Run tests with coverage
go test -coverprofile=coverage.out ./validator

# Display coverage statistics
go tool cover -func=coverage.out

# Clean up
rm coverage.out

This will help assess the current test coverage and identify areas that need improvement to reach the 50% goal.

---

8-11: LGTM! Consider enhancing documentation and evaluating function necessity.

The Validate function correctly uses the Validator interface. However, there are a couple of points to consider:

1. Enhance the comment for better documentation:

-// Validate validates type v.
+// Validate calls the Validate method on the given Validator.
+// It returns an error if the validation fails, or nil if it succeeds.

2. Consider if this function is necessary. It doesn't add much functionality beyond calling v.Validate() directly. If it's not used in multiple places or doesn't provide additional context or error handling, you might want to remove it and use the interface method directly where needed.

To help decide if this function is necessary, let's check its usage:

This will help determine if the Validate function is being used elsewhere in the codebase, which would justify its existence.

Verification successful

Approve Removal of Validate Function

The Validate function is only used in delivery/http/http.go. Consider removing it and replacing its usage with direct calls to the Validator interface to simplify the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check usage of Validate function across the codebase

# Search for import statements of the validator package
echo "Imports of the validator package:"
rg --type go "import.*\".*validator.*\""

# Search for usage of the Validate function
echo "\nUsage of Validate function:"
rg --type go "validator\.Validate\("

Length of output: 559

delivery/http/trace.go (2)

1-8: LGTM: Package declaration and imports are appropriate.

The package name and imports are well-chosen and relevant to the functionality provided in this file.

---

1-23: Great addition of tracing utilities, consider adding tests.

This file introduces well-implemented OpenTelemetry tracing utilities that align with the PR objective of implementing SSE for the Active Orders Query endpoint. The code is clean, well-structured, and follows Go best practices.

To address the comment about testing coverage, consider adding unit tests for these functions. Here's a script to check the current test coverage:

This will help ensure we meet the 50% coverage threshold mentioned in the PR comments.

delivery/http/http.go (3)

5-5: LGTM: Import statement added correctly.

The import for the validator package is correctly added and is necessary for the new functionality in the ParseRequest function.

---

17-30: Consider adding tests and provide more context on SSE implementation.

While the ParseRequest function is a valuable addition, it doesn't directly address the Server-Sent Events (SSE) functionality mentioned in the PR objectives. To align with the project's goals:

1. Consider adding unit tests for the ParseRequest function to improve test coverage. This would help address the concern raised about reaching the 50% coverage threshold.

2. Could you provide more information on how this change relates to the SSE implementation for the Active Orders Query endpoint? Are there additional files or changes that will be part of this PR to fully implement the SSE functionality?

To help understand the current test coverage and identify areas for improvement, we can run the following command:

#!/bin/bash
# Description: Check current test coverage for the delivery/http package

# Run tests with coverage
go test ./delivery/http -coverprofile=coverage.out

# Display coverage statistics
go tool cover -func=coverage.out

# Clean up
rm coverage.out

This will help us identify which functions might need additional test coverage.

---

18-30: LGTM: Well-implemented ParseRequest function, but clarification needed.

The ParseRequest function is well-implemented, encapsulating both unmarshalling and validation logic. It correctly uses type assertion to check if the request implements the Validator interface before performing validation. This approach provides flexibility and adheres to the single responsibility principle.

However, I don't see a direct connection between this function and the Server-Sent Events (SSE) functionality mentioned in the PR objectives. Could you please clarify how this function contributes to the SSE implementation for the Active Orders Query endpoint?

To verify the usage of this new function and its potential relation to SSE, let's search for its usage in the codebase:

Files that changed from the base of the PR and between 81d5aa6 and 5688eb0.

• domain/mvc/orderbook.go (1 hunks)
• orderbook/usecase/orderbook_usecase.go (2 hunks)

• domain/mvc/orderbook.go